Step by Step 实现基于 Cloudera 5.8.2 的企业级安全大数据平台 - Kerberos的整合

大数据技术与架构点击右侧关注，大数据开发领域最强公众号！

暴走大数据点击右侧关注，暴走大数据！

Kerberos简介

之前非常担心的一件事就是如果有人拿到了hdfs超级管理员帐号，直接把数据rm -rf怎么办？有了Kerberos，就可以轻松防止这样的事情发生。Kerberos 协议实现了比“质询－响应”模式协议更高的安全性：第一，在身份验证过程中，所有的数据都使用不同的密码进行加密，避免了相关验证信息的泄漏；第二，客户端和服务器会相互验证对方的身份，避免了 中间人攻击 ；第三，客户端和服务器间的时间差被严格限制，避免了 回放攻击 。与 WINDOWS 系统中的 用户安全令牌 类似， Kerberos 服务通过“ 加密的票据（防止篡改） ”验证用户身份和提供用户访问权限；Kerberos 服务可以通过使用 会话密钥 确保在会话中数据的机密性和完整性。

Kerberos相关术语

Kerberos认证过程

Kerberos 的认证过程如下图所示。我们可以简单的理解为，User 或者 Service 会用 Principal 到 AS 去认证(KRB_AS_REQ)，AS 会返回一个用 Principal Key 加密的 TGT(KRB_AS_REP)，这时候只有 AS 和这个 Principal 的使用者可以识别该 TGT。在拿到加密的 TGT 之后，User 或者 Service 会使用 Principal 的 Key 来解密 TGT，并使用解密后的 TGT 去 TGS 获取 Service Ticket(KRB_TGS_REQ, KRB_TGS_REP)。在 Kerberos 认证的集群中，只有拿着这个 Service Ticket 才可以访问真正的 Server 从而实现自己的业务逻辑(KRB_AP_REQ, KRB_AP_REP)。一般我们将 TGT 的存放文件，称为 Kerberos Confidential 文件，默认的存放目录为/tmp，文件名则由 krb5cc 和用户的 id 组成，例如“/tmp/krb5cc_0”为root的 confidential 文件。

图示：Kerberos 认证过程

Cloudera平台集成Kerberos

Cloudera提供了非常简便的Kerberos集成方式，基本做到了自动化部署。

系统：CentOS 7.2

操作用户：admin

角色分布如下：

角色	部署节点	机器类型
KDC, AS, TGS	192.168.1.1	VM
Kerberos Agent	192.168.1.[2-17]	VM、Master、Slave

假设list_krb_clients文件如下：

192.168.1.2192.168.1.3192.168.1.4192.168.1.5192.168.1.6192.168.1.7192.168.1.8192.168.1.9192.168.1.10192.168.1.11192.168.1.12192.168.1.13192.168.1.14192.168.1.15192.168.1.16192.168.1.17

JDK安装

此过程网上太多教程，不复述。

Kerberos安装

在192.168.1.1上安装服务端：

sudo yum install krb5-server openldap-clients -y

在192.168.1.[2-17]上安装客户端：

sudo pssh -h list_krb_clients -P -l admin -A "sudo yum install krb5-devel krb5-workstation -y"

修改配置

修改krb5.conf，请替换DOMAIN.COM为自定义域名：

[logging]
default = FILE:/var/log/krb5libs.log
kdc = FILE:/var/log/krb5kdc.log
admin_server = FILE:/var/log/kadmind.log

[libdefaults]
default_realm = DOMAIN.COM
dns_lookup_realm = false
dns_lookup_kdc = false
ticket_lifetime = 24h
renew_lifetime = 7d
forwardable = true

[realms]
DOMAIN.COM = {
    kdc = 192.168.1.1
    admin_server = 192.168.1.1
}

[domain_realm]
.domain.com = DOMAIN.COM
domain.com = DOMAIN.COM

分发krb5.conf至所有client：

pscp -h list_krb_clients krb5.conf /tmp
pssh -h list_krb_clients "sudo cp /tmp/krb5.conf /etc"

修改服务端192.168.1.1上的配置文件/var/kerberos/krb5kdc/kdc.conf：

[kdcdefaults]
kdc_ports = 88
kdc_tcp_ports = 88

[realms]
DOMAIN.COM = {
    master_key_type = aes256-cts
    acl_file = /var/kerberos/krb5kdc/kadm5.acl
    dict_file = /usr/share/dict/words
    admin_keytab = /var/kerberos/krb5kdc/kadm5.keytab
    supported_enctypes = aes256-cts:normal aes128-cts:normal des3-hmac-sha1:normal arcfour-hmac:normal des-hmac-sha1:normal des-cbc-md5:normal des-cbc-crc:normal
    max_life = 25h
    max_renewable_life = 8d
}

修改服务端192.168.1.1上的配置文件/var/kerberos/krb5kdc/kadm5.acl，以允许具备匹配条件的admin用户进行远程登录权限：

*/[e-mail] *

由于要支持Java的aes256-cts算法，需要Server和Client都安装JCE，在192.168.1.1上执行：

sudo wget http://download.oracle.com/otn-pub/java/jce/8/jce_policy-8.zip
sudo unzip jce_policy-8.zip
sudo mv UnlimitedJCEPolicyJDK8/*.jar $JAVA_HOME/jre/lib/security
pscp -h list_krb_clients $JAVA_HOME/jre/lib/security/US_export_policy.jar /tmp
pscp -h list_krb_clients $JAVA_HOME/jre/lib/security/local_policy.jar /tmp
pssh -h list -l admin -A "sudo cp /tmp/US_export_policy.jar $JAVA_HOME/jre/lib/security/"
pssh -h list -l admin -A "sudo cp /tmp/local_policy.jar $JAVA_HOME/jre/lib/security/"

创建Kerberos数据库

在192.168.1.1上对数据库进行初始化，默认的数据库路径为/var/kerberos/krb5kdc，如果需要重建数据库，将该目录下的principal相关的文件删除即可，请牢记数据库密码。

sudo kdb5_util create -r DOMAIN.COM -s

启动Kerberos服务

在192.168.1.1上执行：

# 启动服务命令
sudo /bin/systemctl start krb5kdc
sudo /bin/systemctl start kadmin
# 加入开机启动项
sudo /bin/systemctl enable krb5kdc
sudo /bin/systemctl enable kadmin

创建Kerberos管理员principal

# 需要设置两次密码
kadmin.local -q "addprinc cdh-master/admin"

principal的名字的第二部分是admin,那么根据之前配置的acl文件，该principal就拥有administrative privileges，这个账号将会被CDH用来生成其他用户/服务的principal。注意需要先kinit保证已经有principal缓存。Kerberos客户端支持两种，一是使用 principal + Password，二是使用 principal + keytab，前者适合用户进行交互式应用，例如hadoop fs -ls这种，后者适合服务，例如yarn的rm、nm等。

Cloudera整合Kerberos

在此之前，请确保以下前序工作完成：

• KDC已经安装好并且正在运行

• 将KDC配置为允许renewable tickets with non-zerolifetime，我们在之前修改kdc.conf文件的时候已经添加了max_life和max_renewable_life这个2个属性，前者表示服务端允许的Service ticket最大生命周期，后者表示服务端允许的Service ticket更新周期。这2个属性必须分别大于等于客户端对应的配置ticket_lifetime和renew_lifetime。我们假设，不这样进行配置：ticket_lifetime = 8d, max_life = 7d, renew_lifetime = 25h, max_renew_life = 24h，那么可能造成的结果就是当service持有的票据超过24小时没有去更新，在第24.5小时的时候去进行更新，请求会遭到拒绝，报错：Ticket expired while renewing credentials，永远无法进行正常更新。对于Cloudera来说，因为更新机制被透明(Cloudera有renew进程会去定期更新)，即使我们手动使用``modprinc -maxrenewlife 1week krbtgt/[e-mail]` 进行更新，也无济于事。

• 在Cloudera Manager Server上安装openldap-clients；

• 为Cloudera Manager创建了超级管理员principal，使其能够有权限在KDC中创建其他的principals；

再次确认完毕后进入如下步骤：

1. 进入 Cloudera Manager Admin Console 界面并且点击 cluster 右边的按钮选择Enable Kerberos；

2. 点击 Continue，进入下一页进行配置，要注意的是：这里的 Kerberos Encryption Types 必须跟KDC实际支持的加密类型匹配（即kdc.conf中的值），这里使用了默认的aes256-cts，注意，这里的 Kerberos Encryption Types 必须和/etc/krb5.conf中的default_tgs_enctypes、default_tkt_enctypes和permitted_enctypes三个选项的值对应起来，不然会出现集群服务无法认证通过的情况！

3. 点击 Continue，进入下一页，这一页中不勾选 Manage krb5.conf through Cloudera Manager ，否则会修改掉之前配置的acl，造成 enable kerberos 失败；

4. 点击 Continue，进入下一页，输入 Cloudera Manager Principal 的管理员账号和密码，注意输入账号的时候要使用@前要使用全称，本文使用的是cdh-master/[e-mail]；

5. 点击 Continue，进入下一页，导入 KDC Account Manager Credentials；

6. 点击 Continue，进入下一页，Restart Cluster 并且Eenable Kerberos；

之后 Cloudera Manager 会自动重启集群服务，启动之后会提示 Kerberos 已启用。在 Cloudera Manager 上启用 Kerberos 的过程中，会自动做以下的事情：

• 集群中有多少个节点，每个账户就会生成对应个数的 principal ;

• 为每个对应的 principal 创建 keytab；

• 部署 keytab 文件到指定的节点中；

• 在每个服务的配置文件中加入有关 Kerberos 的配置；

其中包括Zookeeper服务所需要的 jaas.conf 和 keytab 文件都会自动设定并读取，如果用户仍然手动修改了Zookeeper的服务，要确保这两个文件的路径和内容正确性。

• keytab 是包含 principals 和加密 principal key 的文件 ；

• keytab 文件对于每个 host 是唯一的，因为 key 中包含 hostname ；

• keytab 文件用于保存纯文本密码，实现到 kerberos上 验证一个主机的 principal ；

启用之后访问集群的所有资源都需要使用相应的账号来访问，否则会无法通过 Kerberos 的 authenticatin。

除此之外，对于特定的服务需要做额外配置，本文只介绍HDFS、YARN、HBase，其余服务请参照官方文档自行进行配置。

对于HDFS，需要开启Web Concole 的认证，以防未认证用户访问资源界面，请在HDFS服务的Configuration中进行配置：

Enable Kerberos Authentication for HTTP Web-Consoles = true

对于YARN，需要开启Web Concole 的认证，以防未认证用户访问资源界面，请在YARN服务的Configuration中进行配置：

Enable Kerberos Authentication for HTTP Web-Consoles = true

对于HBase需要开启 Thrift 认证：

HBase Thrift Authentication = auth

完成修改后，通过Cloudera Manager对HDFS服务进行重启。

相关测试

完成部署后，需要进行相关测试，以验证Kerberos是否被正常开启，本文纯属抛砖引玉，对部分服务进行了验证。

基本功能测试

在192.168.1.1 KDC 服务端上新建principal：

kadmin.local -q "addprinc <user_name>/[e-mail]"

在客户端192.168.1.2上新建principal：

kinit cdh-master/[e-mail]
kadmin -q "addprinc <user_name>/[e-mail]"

销毁ticket缓存：

kdestroy

查看当前ticket缓存，这时应会报错No credentials cache found (ticket cache FILE:/tmp/krb5cc_0)：

klist -f

重新获取ticket：

kinit <user_name>/[e-mail]

查看当前ticket缓存，应该不会报错：

klist -f

Hive功能测试

CLI测试，首先进行principal初始化

kadmin -q "addprinc hive/[e-mail]"
kinit hive/[e-mail]

在没有配置 kerberos 之前，想要通过 hive 用户运行 hive 命令需要执行sudo，现在配置了 kerberos 之后，不再需要 sudo 了，hive 会通过 ticket 中的用户去执行该命令：

CREATE DATABASE test;
USE test;
CREATE TABLE t(id int);
DROP TABLE t;
DROP DATABASE test;

Beeline/JDBC测试：

beeline --verbose=true
beeline > !connect jdbc:hive2://${HIVE_SERVER2_HOSTNAME}:10000/default;principal=hive/${HIVE_SERVER2_HOSTNAME}@DOMAIN.COM;

HUE Sqoop Action测试，唯一需要注意的是，在提交 Action的时候需要选择credential方式，hive shell action请选择 hcat，hive server2 action 请选择hive2，否则无法通过认证。

HBase on HUE功能测试

这里我们需要测试的是在HUE界面中进行HBase查询。在使用HBase时，如果登录HUE时使用的是admin身份，admin会伪装成hue用户发起命令，所以需要使用hbase的超级用户hbase去给hue赋权，才可以使其具备权限，才可以在HUE界面进行HBase查询：

kdestroy
kinit cdh-master/admin
kadmin > addprinc hbase/[e-mail]
kinit hbase/[e-mail]
hbase shell
hbase shell > grant 'hue','RWXCA'

Sqoop on HUE功能测试

在Hue界面进行操作，添加sqoop1作业：

sqoop list-databases --connect jdbc:mysql://${MYSQL_SERVER_FQDN}:3306 --username ${MYSQL_USERNAME} --password ${MYSQL_PASSWD}
sqoop import --connect jdbc:mysql://${MYSQL_SERVER_FQDN}:3306/cm --username ${MYSQL_USERNAME} --password ${MYSQL_PASSWD} --table HOSTS --target-dir /user/admin/tgt -m 1 --delete-target-dir

如何在HUE中提交作业，这里不进行复述。

遇到的问题

Q: kerberos ticket renewer 服务报：Ticket expired while renewing credentials。

A: 这是因为TGT的ticketkrbtgt/[e-mail]的renewlife被设置成了0，这一点可以通过kadmin => getprinc krbtgt/[e-mail]看出来。将krbtgt/[e-mail]的renewlife修改为 7d 即可，方法:

modprinc -maxrenewlife 1week krbtgt/[e-mail]

Q: 提交Spark作业时报错：Delegation Token can be issued only with kerberos or web authentication。

A: 提交spark作业的时候需要指定

spark master = yarn
mode = cluster

Q: Beeline报错，Failed to find any Kerberos tgt。

A: 因为sudo权限下生成的credetial不能用于非sudo权限下的beeline，也就是说不要在申请ticket的时候使用sudo，在执行beeline的时候使用非sudo。

欢迎点赞+收藏+转发朋友圈素质三连

文章不错？点个【在看】吧！ 👇